Parallel build of non-partitioned join hash tables and non-enforced N:1 join hash tables

ABSTRACT

A method for building a hash table over a subset of data in a data set includes mapping keys in the data set to values in the data set using multiple parallel computation threads. Each thread scans a subset of the keys and values and partitioning the subset of the keys and values into multiple partitions. A cumulative count for keys and values in each partition is determined. A hash table with space reserved for each partition is formed based on the determined cumulative counts. Each thread selects one or more partitions and inserts keys and values belonging to the selected one or more partitions into the hash table in the reserved space for those partitions.

BACKGROUND

Embodiments of the invention relate to building join hash tables, inparticular, for a parallel build of a compact, non-partitioned join hashtable, without any latches.

Hash joins are a common operator in business intelligence (BI) queries.Hash joins involve many random accesses to hash tables. Conventionalsystems do partitioned joins by dividing the join hash table intopartitions, so that lookups are focused on small data structures, whichwill fit better in cache. But below a threshold on the hash table size,a non-partitioned join is more efficient because it avoids the costs ofpartitioning.

BRIEF SUMMARY

Embodiments of the invention relate to building hash tables. Oneembodiment includes a method for building a hash table over a subset ofdata in a data set that includes mapping keys to values using multipleparallel computation threads. Each thread scans a subset of the keys andvalues and partitions the subset of the keys and values into multiplepartitions. A cumulative count for the number of keys and values in eachpartition is determined. A hash table with space reserved for eachpartition is formed based on the determined cumulative count for anumber of keys and values in each partition. Each thread selects one ormore partitions and inserts keys and values belonging to the selectedone or more partitions into the hash table in the reserved space forthose partitions.

These and other features, aspects and advantages of the presentinvention will become understood with reference to the followingdescription, appended claims and accompanying figures.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a network architecture for storing and recovering data forfast durability and quick journal-less recovery, according to anembodiment of the present invention;

FIG. 2 shows a representative hardware environment that may beassociated with the servers and/or clients of FIG. 1;

FIG. 3 illustrates a block diagram of an example system for buildingparallel hash tables and compact hash tables, in accordance with anembodiment of the invention;

FIG. 4 illustrates an example compact hash table, in accordance with anembodiment of the invention;

FIG. 5 illustrates an example of a hash join operator flow, inaccordance with an embodiment of the invention;

FIG. 6 illustrates an example of a flow for partitioning, in accordancewith an embodiment of the invention;

FIG. 7 illustrates thread parallelism for hash table creation, inaccordance with an embodiment of the invention;

FIG. 8 illustrates a process for generating a hash table, in accordancewith an embodiment of the invention; and

FIG. 9 illustrates a block diagram showing a process for generating acompact hash table, in accordance with an embodiment of the invention.

DETAILED DESCRIPTION

Aspects of the present invention are described below with reference toflowchart illustrations and/or block diagrams of methods, apparatus(systems), and computer program products, according to embodiments ofthe invention. It will be understood that each block of the flowchartillustrations and/or block diagrams, and combinations of blocks in theflowchart illustrations and/or block diagrams, can be implemented bycomputer program instructions. These computer program instructions maybe provided to a processor of a general purpose computer, specialpurpose computer, or other programmable data processing apparatus toproduce a machine, such that the instructions, which execute via theprocessor of the computer or other programmable data processingapparatus, create means for implementing the functions/acts specified inthe flowchart and/or block diagram block or blocks.

FIG. 1 illustrates a network architecture 100, in accordance with oneembodiment. As shown in FIG. 1, a plurality of remote networks 102 areprovided, including a first remote network 104 and a second remotenetwork 106. A gateway 101 may be coupled between the remote networks102 and a proximate network 108. In the context of the present networkarchitecture 100, the networks 104, 106 may each take any formincluding, but not limited to, a LAN, a WAN, such as the Internet,public switched telephone network (PSTN), internal telephone network,etc.

In use, the gateway 101 serves as an entrance point from the remotenetworks 102 to the proximate network 108. As such, the gateway 101 mayfunction as a router, which is capable of directing a given packet ofdata that arrives at the gateway 101, and a switch, which furnishes theactual path in and out of the gateway 101 for a given packet.

Further included is at least one data server 114 coupled to theproximate network 108, which is accessible from the remote networks 102via the gateway 101. It should be noted that the data server(s) 114 mayinclude any type of computing device/groupware. Coupled to each dataserver 114 is a plurality of user devices 116. Such user devices 116 mayinclude a desktop computer, laptop computer, handheld computer, printer,and/or any other type of logic-containing device. It should be notedthat a user device 111 may also be directly coupled to any of thenetworks in some embodiments.

A peripheral 120 or series of peripherals 120, e.g., facsimile machines,printers, scanners, hard disk drives, networked and/or local storageunits or systems, etc., may be coupled to one or more of the networks104, 106, 108. It should be noted that databases and/or additionalcomponents may be utilized with, or integrated into, any type of networkelement coupled to the networks 104, 106, 108. In the context of thepresent description, a network element may refer to any component of anetwork.

According to some approaches, methods and systems described herein maybe implemented with and/or on virtual systems and/or systems, whichemulate one or more other systems, such as a UNIX system that emulatesan IBM z/OS environment, a UNIX system that virtually hosts a MICROSOFTWINDOWS environment, a MICROSOFT WINDOWS system that emulates an IBMz/OS environment, etc. This virtualization and/or emulation may beimplemented through the use of VMWARE software in some embodiments.

In other examples, one or more networks 104, 106, 108, may represent acluster of systems commonly referred to as a “cloud.” In cloudcomputing, shared resources, such as processing power, peripherals,software, data, servers, etc., are provided to any system in the cloudin an on-demand relationship, therefore allowing access and distributionof services across many computing systems. Cloud computing typicallyinvolves an Internet connection between the systems operating in thecloud, but other techniques of connecting the systems may also be used,as known in the art.

A hash table (HT) is made up of two parts: an array (the actual tablewhere the data to be searched is stored) and a mapping function, knownas a hash function. With a hash table, any value may be used as anindex, such as a floating-point value, a string, another array, or evena structure as the index. This index is called the key, and the contentsof the array element at that index is called the value. Therefore, an HTis a data structure that stores key/value pairs and can be quicklysearched by the key. The hash function is a mapping from the input spaceto the integer space that defines the indices of the array. The hashfunction provides a way for assigning numbers to the input data suchthat the data can then be stored at the array index corresponding to theassigned number.

A hash join is an example of a join process and is used in theimplementation of a relational database management system (DMS). Thetask of a join process is to find, for each distinct value of the joinattribute, the set of tuples in each relation which have that value.Hash joins require an equijoin predicate (a predicate comparing valuesfrom one table with values from the other table using the equalsoperator ‘=’).

An inner join creates a new result table by combining column values oftwo tables (e.g., table1 and table2) based upon the join-predicate. Thequery compares each row of table1 with each row of table2 to find allpairs of rows which satisfy the join-predicate. When the join-predicateis satisfied, column values for each matched pair of rows of A and B arecombined into a result row.

Non-partitioned hash joins perform a join between two inputs by buildinga single HT on one of the inputs, and performing lookups into this HTwith the join columns of the other input. Conventionally, the HT for anon-partitioned join is typically built in one of two ways: builtserially with a single thread, and built in parallel using latches onthe HT buckets. Both ways result in slow HT builds. Further,conventional methods for building HTs focus on the case of provably n:1HTs (when there is an index enforcing that each key has at most 1matching payload), and require a large memory allocation for the casethat such an index is not present, due to fill factor overheads fromlinear probing.

A classic hash join algorithm for an inner join of two relationsproceeds as follows. First prepare an HT of the smaller relation. The HTentries consist of the join attribute and its row. Because the HT isaccessed by applying a hash function to the join attribute, it isquicker to find a given join attribute's rows by using this table thanby scanning the original relation. Once the HT is built, the largerrelation is scanned and the relevant rows from the smaller relation arefound by looking in the HT. The first phase is usually called the“build” phase, while the second is called the “probe” phase. Similarly,the join relation on which the HT is built is called the “build” input,whereas the other input is called the “probe” input. The processrequires that the smaller join relation fits into memory, which issometimes not the case. A simple approach to handling this situationproceeds as follows:

-   -   1. For each tuple r in the build input R.        -   1. Add r to the in-memory HT        -   2. If the size of the HT equals the maximum in-memory size:            -   1. Scan the probe input S, and add matching join tuples                to the output relation            -   2. Reset the HT    -   2. Do a final scan of the probe input S and add the resulting        join tuples to the output relation.

In one or more embodiments, the system 100 utilizes a process forproviding a parallel build of a compact, non-partitioned join HT,without any latches. One or more embodiments perform partitioning on thejoin inner, according to the higher order bits of the hash function, andthen performing builds of each partition in parallel, with a variantform of linear probing.

One or more embodiments provide building HTs. One embodiment includes amethod for building an HT that includes mapping HT keys to values usingmultiple parallel computation threads. Each thread scans a subset of theHT keys and values and partitions the subset of the HT keys and valuesinto multiple partitions. A cumulative count for HT keys and values ineach partition is determined. An HT with space reserved for eachpartition is formed based on the determined cumulative count. Eachthread selects one or more partitions and inserts HT keys and valuesbelonging to the selected one or more partitions into the HT in thereserved space for those partitions.

FIG. 2 shows a representative hardware environment associated with auser device 116 and/or server 114 of FIG. 1, in accordance with oneembodiment. In one example, a hardware configuration includes aworkstation having a central processing unit 210, such as amicroprocessor, and a number of other units interconnected via a systembus 212. The workstation shown in FIG. 2 may include a Random AccessMemory (RAM) 214, Read Only Memory (ROM) 216, an I/O adapter 218 forconnecting peripheral devices, such as disk storage units 220 to the bus212, a user interface adapter 222 for connecting a keyboard 224, a mouse226, a speaker 228, a microphone 232, and/or other user interfacedevices, such as a touch screen, a digital camera (not shown), etc., tothe bus 212, communication adapter 234 for connecting the workstation toa communication network 235 (e.g., a data processing network) and adisplay adapter 236 for connecting the bus 212 to a display device 238.

In one example, the workstation may have resident thereon an operatingsystem, such as the MICROSOFT WINDOWS Operating System (OS), a MAC OS, aUNIX OS, etc. It will be appreciated that other examples may also beimplemented on platforms and operating systems other than thosementioned. Such other examples may include operating systems writtenusing JAVA, XML, C, and/or C++ language, or other programming languages,along with an object oriented programming methodology. Object orientedprogramming (OOP), which has become increasingly used to develop complexapplications, may also be used.

FIG. 3 illustrates a block diagram of an example system 300 for buildingparallel HTs and compact HTs, in accordance with an embodiment of theinvention. In one embodiment, system 300 may include hardware componentssimilar to the architecture shown in FIG. 2. In one embodiment, thesystem 300 includes an HT creation processor 305, a bitmap processor306, a scanning processor 310, a mapping processor 315 and a countingprocessor 320. In one embodiment, the HT creation processor creates acompact HT (CHT) that supports both partitioned and non-partitionedlookups—selected according to the inner cardinality, according to atradeoff of table size versus partitioning processing time. In oneembodiment, the HT creation processor 305 and the scanning processor 310may perform hash table building and probes in parallel, even when the HTlookups are not partitioned. This provides the flexibility to use anon-partitioned HT on the probe side for small-medium inners (to avoidpartitioning costs), while still having fast parallel builds.

In one embodiment, to keep the HT size small, a linear probing HT thathas 100% fill factor in the array of keys and values (payloads) iscreated, and uses a sparse bitmap to almost entirely avoid collisions.The net result is 2× to 3× smaller table space consumption.

Conventional HT creation has focused on n−1 joins, usually withsingle-column keys. However, n−m joins show up in many customer queries.Further, even when data almost (or fully) meets n−1 constraints, theconstraints are not always enforced via indexes. In one embodiment,generalizations of CHT and a join for n−m joins, ‘near’ n−1 joins, andleft-outer joins are provided by the system 300. In one embodiment, avariant of CHT referred to as a compact array table (CAT) that iscollision-free, avoids storing join keys in the HT, and still has nearly100% fill factor, even without dense join keys is provided by the system300.

Query predicates are usually on dimension tables, therefore joins areusually highly filtering processes. Conventional joins assume thatfiltering is performed during the join, and so advocate ‘latematerialization’ (i.e. join just maps key to RID, and only at the endmaps row identifier (RID) to payload columns). In one embodiment, a CHTbitmap is used as a Bloom filter to eliminate most non-matching joinouters—thus processing cost paid is only for 1 bit per inner in thisdata structure (vs width of key + width of RID in late materialization).

In one embodiment, the mapping processor 315 maps HT keys to valuesusing multiple parallel computation threads. In one embodiment, thescanning processor 310 provides for each thread to scan a subset of oneinput to the join, and partitions it, using the high order bits of ahash computed on the join key. In one embodiment, after all of thethreads complete the scan, the threads exchange among themselves thenumber of keys in each partition in the subset they scanned, and thecounting processor 320 sums up the number of keys in each partition. Inone embodiment, the counting processor 320 provides a total count foreach partition by summing up the number of keys received for thatpartition, from each of the scanning threads. In one embodiment, thecounting processor 320 computes a cumulative form of the count—that is,the number of keys in all partitions 0, 1, . . . up to each partition.In one embodiment, the counting processor 320 is embedded in thescanning threads itself, and is not a separate processor.

In one embodiment, the HT creation processor provides for each thread totake ownership of one or more partitions, and builds a sub-range of theHT for that partition. In the HT, the sub-range of the array holdingkeys and payloads is indicated by a starting position given by thecumulative count of the partitions up to (and excluding) the one beingbuilt, and extends to a length equal to the number of keys in thispartition. In one embodiment, any linear probing (or quadratic probingor other collision resolution technique) is cycled around within thispartition alone.

In one embodiment, the system 300 provides for building a CHT asfollows. In one embodiment, the scanning processor 310 scans the input(e.g., partitioned as above), and for each key, a hash function isperformed on the input and the bit map processor 306 inserts the resultinto a bitmap. In one embodiment, if there is a collision, it is notknown if it is due to a duplicate key or just a hash collision. In thecase of duplicate keys, it is desired to eliminate them (and thus savememory), rather than placing them into the CHT. In one embodiment, theduplicate keys are treated as a hash collision until the collision chainlength grows beyond a threshold (e.g., 2). At that point, in oneembodiment the bitmap processor 305 begins tracking the actual keys thatare seen, so that in the future if that same hash bucket is hit thesystem 300 can detect if it is a collision or not. In one embodiment,two processes may be used to perform the tracking.

In one embodiment, tracking is provided as follows. In one embodiment, asmall local HT or similar data structure is used by the bitmap processor306 to detect and eliminate highly frequent duplicate keys. Whentracking starts, a key is placed into the data structure because of highcollision chain length. In one embodiment, any key that is not detectedas a duplicate in this structure is placed into the CHT bitmap by thebitmap processor 306 and is treated as collisions.

Another embodiment for tracking is provided as follows. In oneembodiment, all keys that collide to a chain length of, for example, >2,are taken and placed into an ‘overflow’ HT. The crucial differencecompared to the first tracking embodiment is that these overflow keysare never inserted into the HT. This has huge performance benefitsduring probe time because it is known that the linear probe chain willnever be >2.

In one embodiment, the CHT creation process continues as follows. In oneembodiment, the counting processor 320 computes cumulative populationcounts for the bitmap provided by the bitmap processor 306. In oneembodiment, the scanning processor 310 scans the input again, insertskeys and values/payloads into a compacted array, using the populationcounts from the counting processor 320. In one example, a few duplicatekeys may be encountered. In this case, in one embodiment, the CHTcreation processor marks the key specially as a duplicate so that thecost of returning the marked keys as join matches is avoided, and alsopotentially for avoiding the processing cost of copying them into theCHT (although the space the keys take up in the CHT cannot bereclaimed).

FIG. 4 illustrates an example compact HT 420, in accordance with anembodiment of the invention. Logically, a CHT 420 is a linear probingHT, with very high sparseness (almost no collisions), but in oneembodiment all the empty buckets are compressed out as can be seen bycomparing the CHT 420 to the un-compressed table 410. In one embodiment,the CHT 420 is made up of two portions: an array of the non-emptybuckets 420, and a bitmap 425 (sized to the original uncompressed HTsize indicating for each bucket whether it was occupied or not.

In one embodiment, the CHT 420 includes an array of keys (indicated byKn, where n is a positive integer) and payloads or values (indicated bypn), whose size is the cardinality of the input on which the CHT isbuilt. The Bitvector has a size equal to the size of the HT in the CHT,and it indicates occupied buckets of that HT. In one example, for every64-bits, a pre-computed 32-bit prefix population count is stored.

FIG. 5 illustrates an example of a hash join operator flow 500, inaccordance with an embodiment of the invention. There is more to fastjoins than just having fast and compact HTs. In one embodiment CHTs areincorporated into a hash join and stitched into a larger query plan. Inone embodiment, a two-table equijoin is implemented, and this is fit ina standard query plan. In one embodiment, two tables are being joined,with equality predicate a=b, where a and b are typically single-column,but may be composite.

FIG. 6 illustrates an example of a flow 600 for partitioning, inaccordance with an embodiment of the invention. In one embodiment, oneof the inputs to a join is scanned, local predicates are applied, an HTis built mapping join columns to auxiliary values needed during thejoin, and then the other input to the join is scanned, and the joincolumn values are looked up into the HT. In one embodiment, for buildingthe HT, each thread scans a subset of blocks (work stealing), where eachthread has its own local HT (no synchronization). HTs are partitionedfor cache-efficiency.

FIG. 7 illustrates thread parallelism for HT creation 700, in accordancewith an embodiment of the invention. Partitioned joins (PJ) are goodboth for cache efficiency and also enable easy parallelism during HTbuild. But in many cases non-partitioned lookups (NPJ) are just asefficient, and they avoid the cost of partitioning. NPJ means building asingle HT over the entire join input. Conventionally, this means thebuild becomes very slow (either serial, or latching overhead due to manythreads hitting the same HT—especially if there are popular keys as canhappen in n:m and non-enforced n:1 cases). To avoid this slowdown, inone embodiment, one of the join inputs is always partitioned. Then,based on the number of actual qualifying keys, for inners below athreshold (calibrated beforehand), a non-partitioned join is chosen. Inone embodiment, even for this NPJ, a single physical CHT is formed. Buteach thread builds into a sub-range of this CHT bitmap (and any linearprobing is cycled around within each sub-range). This way, there is nocontention, no need for latches on the HT. The bitmap of a CHT is builtbased on linear probing. So the natural way to build this is to build anactual linear probe HT—allocating space for an array of |HT| keys,inserting keys and payloads into it with linear probing, and thenforming the bitmap based on which buckets are occupied. In oneembodiment, for CHT it is desired to have a very sparsely filled HT.

It is noted that if keys are all guaranteed unique (i.e. unique keyswith an enforced uniqueness constraint), linear probing may be performedwithout inserting keys: the position of a key in a linear probe HT canbe inferred by just performing linear probing on the CHT bitmap.

But, enforced PK constraints are not very popular with databaseapplications (DBAs) because they impose a unique index maintenance costduring inserts. However, queries sometimes care only for the first matchfor a join outer—this commonly arises with existential sub-queries andalso with group-by. In this case, the input could have duplicate keys,but these should be eliminated, since the join doesn't need them.

FIG. 8 illustrates a process 800 for generating an HT, in accordancewith an embodiment of the invention. In one embodiment, in block 810process 800 provides for mapping keys (values of the join column) toauxiliary values using multiple parallel computation threads. In oneembodiment, in block 820 each thread scans a subset of the keys andvalues and partitions the subset of the keys and values into multiplepartitions. In one embodiment, in block 830 a cumulative count for keysand values in each partition is determined. In one embodiment, in block840 a hash table with space reserved for each partition is formed basedon the determined cumulative count. In one embodiment, in block 850 eachthread selects one or more partitions and inserts keys and valuesbelonging to the selected one or more partitions into the hash table inthe reserved space for those partitions.

In one embodiment, process 800 may choose the subset of the keys andvalues from a subset of a join input. In one embodiment, partitioning ofthe subset of the keys and values is performed using bits (e.g., highorder) of a hash value computed on a column used in a join predicate. Inone embodiment, process 800 may include that determining the cumulativecount for keys and values in each partition includes that each threadexchanges with other threads a number of keys in each partition in itssubset, and determines the number of keys for each of the partitions bysumming the values received from other threads for those partitions, andsums the determined number of keys for each of the partitions fordetermining the cumulative count up to each partition. For example, thecumulative count up to partition 5 is the sum of the number of keys inpartitions 1, 2, 3, and 4.

In one embodiment, process 800 may include that each thread takesownership of one or more partitions and builds a sub-range of the hashtable for that partition. The sub-range includes a sub-range of an arrayholding keys and payloads and is indicated by a starting position givenby the cumulative count of the partitions up to (and excluding) acurrent partition being built, and extends to a length equal to a numberof keys in the current partition. In one embodiment, process 800 mayfurther include creating a compact hash table by: scanning the subset ofthe hash table keys and values, and for each key, performing a hashoperation and inserting hashed keys into a bitmap; determiningcumulative population counts for hash table keys and values for thebitmap; repeating scanning of the subset of the hash table keys andvalues; and inserting the hash table keys and values into a compactedarray using the cumulative population counts. In one embodiment, process800 may provide that the compacted array for the compact hash tablecontains one entry for each distinct key.

In one embodiment, process 800 may include treating duplicate keys as ahash collision until a collision chain length reaches a predeterminedthreshold, and then tracking of hash table keys. In one embodiment,tracking hash table keys in process 800 may include: inserting theduplicate keys in a local data structure; and using the local datastructure for detecting and eliminating frequent duplicate keys. In oneembodiment, the un-detected keys in the local data structure are treatedas collisions and placed in the bitmap. In another embodiment, trackingin process 800 may include placing the duplicate keys into an overflowhash table. In one embodiment, the duplicate keys are marked foravoidance of returning the marked duplicate keys as join matches andavoiding copying the marked duplicate keys into the hash table.

FIG. 9 illustrates a block diagram showing a process 900 for generatinga CHT, in accordance with an embodiment of the invention. In oneembodiment, in block 910 a thread executes using a processor forscanning a subset of keys and values, and for each key, performs a hashoperation and inserting hashed keys into a bitmap structure. In oneembodiment, in block 920 a cumulative population count of hash tablekeys and values for the bitmap is determined. In one embodiment, inblock 930 scanning of the subset of the keys and values is repeated. Inone embodiment, in block 940 the hash table keys and values are insertedinto a compacted array using the cumulative population counts. In oneembodiment, process 900 includes that the compacted array for thecompact hash table contains one entry for each distinct key.

In one embodiment, process 900 may include that duplicate keys aretreated as a hash collision until a collision chain length reaches apredetermined threshold (e.g., 2), and then tracking of hash table keysis performed. In one embodiment, in process 900, tracking of keys mayinclude inserting the duplicate keys in a local data structure, andusing the local data structure for detecting and eliminating frequentduplicate keys. In one embodiment, un-detected keys in the local datastructure are treated as collisions and placed in the bitmap. In oneembodiment, tracking of hash table keys in process 900 may includeplacing the duplicate keys into an overflow hash table. In oneembodiment, duplicate keys are marked for avoidance of returning themarked duplicate keys as join matches and avoiding copying the markedduplicate keys into the hash table.

As will be appreciated by one skilled in the art, aspects of the presentinvention may be embodied as a system, method or computer programproduct. Accordingly, aspects of the present invention may take the formof an entirely hardware embodiment, an entirely software embodiment(including firmware, resident software, micro-code, etc.) or anembodiment combining software and hardware aspects that may allgenerally be referred to herein as a “circuit,” “module” or “system.”Furthermore, aspects of the present invention may take the form of acomputer program product embodied in one or more computer readablemedium(s) having computer readable program code embodied thereon.

Any combination of one or more computer readable medium(s) may beutilized. The computer readable medium may be a computer readable signalmedium or a computer readable storage medium. A computer readablestorage medium may be, for example, but not limited to, an electronic,magnetic, optical, electromagnetic, infrared, or semiconductor system,apparatus, or device, or any suitable combination of the foregoing. Morespecific examples (a non-exhaustive list) of the computer readablestorage medium would include the following: an electrical connectionhaving one or more wires, a portable computer diskette, a hard disk, arandom access memory (RAM), a read-only memory (ROM), an erasableprogrammable read-only memory (EPROM or Flash memory), an optical fiber,a portable compact disc read-only memory (CD-ROM), an optical storagedevice, a magnetic storage device, or any suitable combination of theforegoing. In the context of this document, a computer readable storagemedium may be any tangible medium that can contain, or store a programfor use by or in connection with an instruction execution system,apparatus, or device.

A computer readable signal medium may include a propagated data signalwith computer readable program code embodied therein, for example, inbaseband or as part of a carrier wave. Such a propagated signal may takeany of a variety of forms, including, but not limited to,electro-magnetic, optical, or any suitable combination thereof. Acomputer readable signal medium may be any computer readable medium thatis not a computer readable storage medium and that can communicate,propagate, or transport a program for use by or in connection with aninstruction execution system, apparatus, or device.

Program code embodied on a computer readable medium may be transmittedusing any appropriate medium, including but not limited to wireless,wireline, optical fiber cable, RF, etc., or any suitable combination ofthe foregoing.

Computer program code for carrying out operations for aspects of thepresent invention may be written in any combination of one or moreprogramming languages, including an object oriented programming languagesuch as Java, Smalltalk, C++ or the like and conventional proceduralprogramming languages, such as the “C” programming language or similarprogramming languages. The program code may execute entirely on theuser's computer, partly on the user's computer, as a stand-alonesoftware package, partly on the user's computer and partly on a remotecomputer or entirely on the remote computer or server. In the latterscenario, the remote computer may be connected to the user's computerthrough any type of network, including a local area network (LAN) or awide area network (WAN), or the connection may be made to an externalcomputer (for example, through the Internet using an Internet ServiceProvider).

Aspects of the present invention are described below with reference toflowchart illustrations and/or block diagrams of methods, apparatus(systems) and computer program products according to embodiments of theinvention. It will be understood that each block of the flowchartillustrations and/or block diagrams, and combinations of blocks in theflowchart illustrations and/or block diagrams, can be implemented bycomputer program instructions. These computer program instructions maybe provided to a processor of a general purpose computer, specialpurpose computer, or other programmable data processing apparatus toproduce a machine, such that the instructions, which execute via theprocessor of the computer or other programmable data processingapparatus, create means for implementing the functions/acts specified inthe flowchart and/or block diagram block or blocks.

These computer program instructions may also be stored in a computerreadable medium that can direct a computer, other programmable dataprocessing apparatus, or other devices to function in a particularmanner, such that the instructions stored in the computer readablemedium produce an article of manufacture including instructions whichimplement the function/act specified in the flowchart and/or blockdiagram block or blocks.

The computer program instructions may also be loaded onto a computer,other programmable data processing apparatus, or other devices to causea series of operational steps to be performed on the computer, otherprogrammable apparatus or other devices to produce a computerimplemented process such that the instructions which execute on thecomputer or other programmable apparatus provide processes forimplementing the functions/acts specified in the flowchart and/or blockdiagram block or blocks.

The flowchart and block diagrams in the Figures illustrate thearchitecture, functionality, and operation of possible implementationsof systems, methods, and computer program products according to variousembodiments of the present invention. In this regard, each block in theflowchart or block diagrams may represent a module, segment, or portionof instructions, which comprises one or more executable instructions forimplementing the specified logical function(s). In some alternativeimplementations, the functions noted in the block may occur out of theorder noted in the figures. For example, two blocks shown in successionmay, in fact, be executed substantially concurrently, or the blocks maysometimes be executed in the reverse order, depending upon thefunctionality involved. It will also be noted that each block of theblock diagrams and/or flowchart illustration, and combinations of blocksin the block diagrams and/or flowchart illustration, can be implementedby special purpose hardware-based systems that perform the specifiedfunctions or acts or carry out combinations of special purpose hardwareand computer instructions.

References in the claims to an element in the singular is not intendedto mean “one and only” unless explicitly so stated, but rather “one ormore.” All structural and functional equivalents to the elements of theabove-described exemplary embodiment that are currently known or latercome to be known to those of ordinary skill in the art are intended tobe encompassed by the present claims. No claim element herein is to beconstrued under the provisions of 35 U.S.C. section 112, sixthparagraph, unless the element is expressly recited using the phrase“means for” or “step for.”

The terminology used herein is for the purpose of describing particularembodiments only and is not intended to be limiting of the invention. Asused herein, the singular forms “a”, “an” and “the” are intended toinclude the plural forms as well, unless the context clearly indicatesotherwise. It will be further understood that the terms “comprises”and/or “comprising,” when used in this specification, specify thepresence of stated features, integers, steps, operations, elements,and/or components, but do not preclude the presence or addition of oneor more other features, integers, steps, operations, elements,components, and/or groups thereof.

The corresponding structures, materials, acts, and equivalents of allmeans or step plus function elements in the claims below are intended toinclude any structure, material, or act for performing the function incombination with other claimed elements as specifically claimed. Thedescription of the present invention has been presented for purposes ofillustration and description, but is not intended to be exhaustive orlimited to the invention in the form disclosed. Many modifications andvariations will be apparent to those of ordinary skill in the artwithout departing from the scope and spirit of the invention. Theembodiment was chosen and described in order to best explain theprinciples of the invention and the practical application, and to enableothers of ordinary skill in the art to understand the invention forvarious embodiments with various modifications as are suited to theparticular use contemplated.

What is claimed is:
 1. A method for building a hash table over a subsetof data in a data set comprising: mapping keys in the data set to valuesin the data set using multiple parallel computation threads; each threadscanning a subset of the keys and values and partitioning the subset ofthe keys and values into a plurality of partitions; determining acumulative count for a number of keys and values in each partition;forming a hash table with space reserved for each partition based on thedetermined cumulative counts; each thread selecting one or morepartitions and inserting keys and values belonging to the selected oneor more partitions into the hash table in the reserved space for thosepartitions; and creating a compact hash table comprising a bitmap and acompacted array.
 2. The method of claim 1, wherein the data setcomprises an input to a join operation, and partitioning the subset ofkeys and values is performed using bits of a hash value computed on acolumn used in a join predicate.
 3. The method of claim 1, whereindetermining the cumulative count for keys and values in each partitioncomprises each thread exchanging, with other threads, a number of keysin each partition in its subset, and summing a number of keys receivedfor each partition from each of the other threads to determine thenumber of keys for each of the partitions, and summing the number ofkeys for each of the partitions for determining the cumulative count. 4.The method of claim 3, wherein each thread takes ownership of one ormore partitions and builds a sub-range of the hash table for thatpartition, and the sub-range comprises a sub-range of an array holdingkeys and payloads and starts at a position indicated by the cumulativecount of the partitions up to and excluding a current partition beingbuilt, and extends to a length equal to a number of keys in the currentpartition.
 5. The method of claim 1, wherein creating the compact hashtable comprises: scanning the subset of the keys, and for each key,performing a hash operation and inserting hashed keys into the bitmap;determining cumulative population counts for keys and values within thebitmap; repeating scanning of the subset of the keys and values; andinserting the keys and values into the compacted array using thecumulative population counts.
 6. The method of claim 5, whereinduplicate keys are treated as a hash collision until a collision chainlength reaches a predetermined threshold, and then tracking of keys isperformed.
 7. The method of claim 6, wherein tracking of keys comprises:inserting the duplicate keys in a local data structure; and using thelocal data structure for detecting and eliminating frequent duplicatekeys, wherein un-detected keys in the local data structure are treatedas collisions and placed in the bitmap.
 8. The method of claim 6,wherein tracking of keys comprises: placing the duplicate keys into anoverflow hash table.
 9. The method of claim 5, wherein duplicate keysare marked for avoidance of returning the marked duplicate keys as joinmatches and avoiding copying the marked duplicate keys into the hashtable.
 10. A computer program product for building a hash table over asubset of data in a data set, the computer program product comprising acomputer readable storage medium having program code embodied therewith,the program code executable by a processor to: map, by the processor,hash keys in the data set to values in the data set using multipleparallel computation threads; scan, by each thread, a subset of the keysand values and partitions the subset of the keys and values into aplurality of partitions; determine, by the processor, a cumulative countfor a number of keys and values in each partition; form, by theprocessor, a hash table with space reserved for each partition based onthe determined cumulative counts; select, by each thread, one or morepartitions and inserts its keys and values into the hash table in thereserved space for those partitions; and create, by the processor, acompact hash table comprising a bit a and a compacted array.
 11. Thecomputer program product of claim 10, wherein: the data set comprises aninput to a join operation; partitioning the subset of the keys andvalues is performed using bits of a hash value computed on a column usedin a join predicate; and the cumulative count for keys and values ineach partition is determined based on each thread exchanging, with otherthreads, a number of keys in each partition in its subset, and summing anumber of keys received for each partition from each of the otherthreads to determine the number of keys for each of the partitions, andsumming the number of keys for each of the partitions for determiningthe cumulative count.
 12. The computer program product of claim 11,wherein each thread takes ownership of one or more partitions and buildsa sub-range of the hash table for that partition, wherein the sub-rangecomprises a sub-range of an array holding keys and payloads and startsat a position indicated by the cumulative count of the partitions up toa current and excluding a current partition being built, and extends toa length equal to a number of keys in the current partition.
 13. Thecomputer program product of claim 10, wherein the compact hash table iscreated by: scanning the subset of the keys, and for each key,performing a hash operation and inserting hashed keys into the bitmap;determining cumulative population counts of keys and values within thebitmap; repeating scanning of the subset of the keys and values; andinserting the keys and values into the compacted array using thecumulative population counts, wherein duplicate keys are treated as ahash collision until a collision chain length reaches a predeterminedthreshold, and then tracking of keys is performed.
 14. The computerprogram product of claim 13, wherein tracking of keys comprises:inserting the duplicate keys in a local data structure; and using thelocal data structure for detecting and eliminating frequent duplicatekeys, wherein un-detected keys in the local data structure are treatedas collisions and placed in the bitmap.
 15. The computer program productof claim 13, wherein tracking of keys comprises: placing the duplicatekeys into an overflow hash table, wherein duplicate keys are marked foravoidance of returning the marked duplicate keys as join matches andavoiding copying the marked duplicate keys into the hash table.